Evaluation Of The Stability Of Malaysian Vps With Unlimited Traffic Under Long-term High Concurrency Environment

1.

test overview and objectives

① test goal: evaluate the stability and availability of malaysia (kuala lumpur node) vps under long-term high concurrent access.
② test cycle: 72 hours of continuous stress testing, with intermittent peak playback to simulate actual business peaks.
③ test tools: wrk, tsung, iperf3, ping, sar, iostat, netstat.
④ test scenario: static file download, dynamic interface request (php+nginx), websocket long connection.
⑤ indicators to focus on: rps (requests/second), p95 latency, cpu/memory usage, network throughput, packet loss rate and error rate.

2.

tested vps configuration and initial environment

① vps-a (standard): 4 vcpu intel xeon, 8gb ram, 160gb nvme, 1gbps public network peak, unlimited traffic billing;
② vps-b (enhanced): 8 vcpu, 16gb ram, 320gb nvme, 2gbps guaranteed bandwidth, with local anti-ddos basic protection (20gbps cleaning);
③ operating system: ubuntu 20.04 lts, kernel 5.4 (with sysctl adjustments for network optimization);
④ software stack: nginx 1.18, php-fpm 7.4, redis 6, mysql 8;
⑤ network topology: the customer domain name shop-example.my points to the vps, and domestic/international cdn is used to cache static resources.

3.

stress test data and specific values ​​(key results)

① static download (10kb file), single machine wrk 10k concurrency: vps-a peak throughput 820 mbps, p95 120 ms;
② dynamic interface (100ms back-end processing), tsung 10k concurrent distribution: vps-a average rps 9,200, p95 320 ms, error rate 0.8%;
③ 72-hour continuous stability: after vps-a runs smoothly for 48 hours, the cpu averages 62%, and the error rate rises to 1.5% within 72 hours (mainly due to short-term connection timeout);
④ network packet loss: the iperf3 long connection test shows a packet loss rate of 0.02% (representing public network jitter);
⑤ disk io: the peak of nvme random read and write iops is 28,000, and the average delay is 1.6 ms, which has not become a bottleneck.

4.

comparison table: configuration and stress test results (sample data)

5.

real case: e-commerce flash sale (flashsale.shop-example.my) in action

① scenario description: an e-commerce company simulates a flash sale event on 2025-11-11, with expected concurrency of 15,000~30,000;
② deployment strategy: the main site uses vps-b as the origin site, static resources are cached by cdn (cloudflare + local cdn), and rate limit and page caching are enabled;
③ results: cdn hit rate 85%, origin site requests dropped 6.5 times, origin site peak concurrency maintained at 7,200, vps-b cpu peak 78%;
④ ddos events: encountered small udp/icmp scans and syn floods during the event, the provider's cleaning threshold (20gbps) was triggered in time, malicious traffic was discarded, and the business was not interrupted;
⑤ lessons learned: api interfaces that miss the cache need to rely on backend horizontal expansion or use worker caching strategy to reduce instantaneous pressure.

6.

tuning suggestions and protection strategies

① kernel and network: it is recommended to set net.ipv4.tcp_tw_reuse=1, tcp_fin_timeout=15, somaxconn=65535, and add net.core.somaxconn and net.ipv4.tcp_max_syn_backlog;
② application layer: enable keepalive, gzip/brotli, enable long cache of static resources and cooperate with cdn cache layering;
③ connection number control: properly configure nginx worker_connections and upstream keepalive to avoid frequent establishment of short connections;
④ ddos protection: use cdn/cloud firewall for pre-cleaning, set rate limit, ip blacklist and syn cookies;
⑤ monitoring and drills: it is recommended to combine prometheus + grafana, set alarms and conduct regular capacity drills (chaos testing, traffic playback).